A browser is a computer application program that enables a computer user to view (i.e., browse) web pages and other resources. The user specifies a resource identifier, such as a universal resource identifier (URI), which directs the browser to the specified resource. Typically, as the user browses resources, the browser maintains a history of visits to resources that have been visited, and provides tools whereby the user can access the history to re-visit certain resources. Ideally, the history and the tools would enable the user to quickly re-visit preferred resources. Unfortunately, the tools offered by current browsers to re-visit preferred resources are often time consuming or confusing to use.
For example, most browsers employ a “back” button. If the user selects the “back” button, the browser returns to the previous resource most recently visited during the current browsing session. A browsing session refers to resource browsing that occurs between the time a browser is launched and when the browser is closed. Thus, the traditional “back” button does not allow a user to access a history of resource visits across multiple sessions.
In addition, the traditional “back” button does not distinguish between a visit to one resource and a visit to another in terms of user preference. Therefore, if the user browses many resources, and then wants to return to a resource that was previously visited early in the session, the user must repeatedly select the “back” button many times through intervening visits to resources to get back to the desired resource. Such repeated selection of the “back” button can be time consuming, and can be confusing to the user if the user does not readily recognize the resource that he/she wants. Furthermore, the traditional navigation stack used by the traditional back button replaces a prior navigation path branching from a resource with a subsequent navigation path branching from the same resource. As a result, the traditional back button will not allow a user to navigate back certain paths when multiple paths branch from a resource visit.
Some browsers do maintain inter-session histories (histories available across browser sessions) and tools to access those histories. For example, INTERNET EXPLORER by MICROSOFT, provides History, a list of all the visited resource visits up to a point in the past, often determined by the memory storage constraints. These can be used to search for a resource seen on a particular date. However, this is not closely integrated with the current resource navigation session and lacks details of the navigation information and resource descriptions. Consequently it takes a considerable amount of time to identify the desired resource in the list. Similarly, INTERNET EXPLORER by MICROSOFT provides a “Favorites” menu item, with which a user can designate a currently visited resource as a favorite and later return to that resource in the same session or another session. Although “Favorites” provides some level of historical recall by listing the resources that have been visited in the past, the feature is not highly effective in supporting revisitation of a resource. The reason is that users tend to fill the favorites list or tree type directory with many resources and it becomes difficult for the user to later locate the favorite resource identifier in the list or directory. In some instances, it may take the user longer to locate the favorite resource in the “Favorites” than it would be to find the resource by some other means (e.g., a search engine).
An “autocomplete” function also tends to obviate the “Favorites” and “History”. “Autocomplete” is a function that automatically completes a resource identifier as the identifier is being typed. As the user types in the identifier, the “autocomplete” finds one or more previously visited resource identifiers that match the identifier being typed in and presents the matching identifier(s) to the user. A user who remembers the first few symbols in a resource identifier can begin typing the symbols, and then select one of the identifiers presented by the “autocomplete” function. Often, a user will opt for the “autocomplete” function instead of looking up the resource identifier, i.e., URI in the long “History” list or the “Favorites” list when it is overly populated. Unfortunately, the “autocomplete” function is not a complete solution because it requires that the user remember symbols in the resource identifier.
Another tool often provided by browsers is the “Address Dropdown” menu which simply presents a list of resource identifiers, typically URIs, of previously typed-in resources. Even after a relatively short browsing session, the “Address Dropdown” tools can be filled with a large number of typed-in resource identifiers. Users are often confused by such long lists of identifiers, and can spend a lot of time searching such lists for previously visited resources since the user may not correctly remember the precise URL of the desired resource. In addition, the resource identifiers are typically not presented in any particular order or with any preference information that may assist the user in quickly identifying a desired resource that was previously visited.
As such, traditional browsing tools are not as robust as they could be in enabling a user to quickly and efficiently locate preferred resources that have been visited before.